The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but provided by the present invention. Some such contributions of the present invention may be specifically pointed out below, while other such contributions of the present invention will be apparent from their context.
In an Ethernet bridge, a Forwarding Database (FDB) is used to support queries by a forwarding process to determine whether a received Ethernet frame, with given values of a Destination MAC (DMAC) address and optionally a virtual local access network identifier (VLAN ID), is to be forwarded through or filtered out. Each entry in the FDB consists of a MAC address, an identifier of the port on which the MAC address was received, and optionally a VLAN ID. According to different attributes, the entries in the FDB can be divided into static and dynamic entries. The static entries can be manually configured by a management action, such as performed by network operators or administrators, and are never aging until being manually deleted from the FDB. In contrast, the dynamic entries are automatically entered into the FDB by an FDB learning process and would age out after a configurable life cycle. Upon invoking, the FDB learning process will create or update a forwarding entry that specifies a reception port for the source MAC (SMAC) address and the VLAN ID of a received frame. In particular, the SMAC address of each received frame is stored into the FDB so that future frames destined for that address can be forwarded only to a bridge interface on which that SMAC address has been learnt. For example, when an Ethernet frame arrives at the bridge, the bridge will inspect for the DMAC address in a frame header and look up the FDB for information about where to deliver the frame. If the lookup ends up in failure, i.e., the DMAC address is not found in the FDB, usually the frame will be flooded out of all ports in the same broadcast domain. In other words, frames destined for unrecognized addresses are forwarded out of all bridge interfaces except the one through which the frame is received. In this manner, traffic on the attached LANs can be minimized.
Although the FDB may be a highly workable scheme for forwarding Ethernet frames, it is vulnerable to network attacks from all kinds of illegal invader. One common form of the attack is a MAC flooding attack, which has been purposefully designed based on the fact that the size of the FDB is limited. In a typical MAC flooding attack, a large number of Ethernet frames are sent to the Ethernet bridge from a potential attacker and each Ethernet frame contains respective different SMAC address. Upon receipt at the Ethernet bridge, the limited FDB would be rapidly occupied or populated with a large number of SMAC addresses even if a very large size of FDB is supported. In this manner, the MAC flooding attack not only consumes the limited FDB, but also forces some other legal MAC addresses out of the FDB. As discussed above, if the MAC addresses are not found in the FDB when forwarding, the Ethernet frames related to these MAC addresses will be sent out in a broadcast way. This results in degradation of service quality and the leak of information to the attacker, who may capture the broadcast packets and analyze them to obtain sensitive or confidential data. For an easy understanding of the MAC flooding attack, discussion will be made with reference to FIG. 1.
FIG. 1 schematically illustrates a scenario in which a network attacker launches a MAC flooding attack against an Ethernet switch. As illustrated in FIG. 1, an attacker starts a MAC flooding attack from a host 2 with numerous Ethernet frames and upon the attack, an FDB residing in an Ethernet switch 1 will be immediately and fully occupied. When a host 1, acting as a normal or legal user, tries to communicate with a server 1, the MAC address of the host 1 (00: 03: 5a: 23: 01: 01), which has not yet been learnt, needs to be learnt through an FDB learning process. However, the MAC address of the host 1 cannot be inserted into the FDB because the FDB has been full and no room for such insertion. Due to this situation, all the traffic from the server 1 to the host 1 will be sent in a broadcast manner and the attacker at the host 2 can easily receive all the Ethernet frames from the server 1 to the host 1, which causes serious security issues and brings about great degradation of communication performance.
Although some standards or techniques, such as a port security technique, IEEE 802.1X, a static MAC address technique and a MAC Access Control List (ACL), have been proposed for protecting the Ethernet switch from being attacked by illegal invaders, they cannot provide a once-for-all approach and are more or less problematic. Take the port security technique for example, among other defects, it does not work well with the movement of a station across multiple ports when the secure MAC addresses is manually configured and may increase operational expense (OPEX). As for the IEEE 802.1X, it introduces Authentication, Authorization, and Accounting (AAA) servers so as to ensure only legal MAC addresses being learnt. However, cooperative working among the servers may weaken functionality of each server and thus provide limited capability of protecting the Ethernet switch from the MAC flooding attack. In addition, it may also bring out OPEX issues. As for the static MAC address technique, it may have the similar defects as the port security technique as mentioned above. Regarding the MAC ACL, it may prevent the Ethernet frames with fake or illegal MAC addresses from being forwarded. However, it cannot prevent the fake MAC addresses from being stored into the FDB.
In addition to the MAC flooding attack as discussed above, the Ethernet switch, when operated in a distributed manner, may also face a synchronization issue, as will be discussed below in connection with FIG. 2.
FIG. 2 schematically illustrates a distributed Ethernet switch with multiple line cards. As illustrated in FIG. 2, in the distributed Ethernet switch that comprises multiple line cards (such as line cards 1, 2, . . . , n) carrying respective ports and interconnected by a backplane, each line card may play roles as an ingress line card and an egress line card both and have its own FDB. When an ingress line card receives a frame, it performs SMAC learning (i.e., the FDB learning process) and DMAC lookup processing. For the SMAC learning, a new FDB entry may be inserted into the FDB or existing FDB entry may be refreshed. After that, the new FDB entry will be synchronized to all other line cards.
For example, a host 1 is running a Voice over Internet Protocol (VoIP) application through Virtual Router Redundancy Protocol (VRRP) routers, and a host 2 is downloading files from an FTP server. MAC addresses appeared on the line cards 1, 3 and n−1 should be distributed to other line cards so that the FDBs in all line cards are aligned or synchronized. Due to different time sensitive requirements, the VoIP application is more time-sensitive than the FTP application.
For the VoIP application, synchronization of the MAC address of the VRRP router among the line cards within mini-seconds is required. In view of this, when a VRRP router switchover occurs, the port change associated with the VRRP MAC address in the FDB should be synchronized to all the line cards promptly.
For the FTP application, synchronization of the gateway MAC address to the FTP server among the line cards within seconds is acceptable. Therefore, in case of the MAC movement, the change of the MAC address in the FDB being synchronized to all line cards within several seconds is expected.
Currently, several mechanisms are considered in the specific synchronization implementations. First, the synchronization is executed immediately after an SMAC address is learnt. However, this is not commonly used because it will consume too much system resources such as bandwidth and/or CPU resources. For example, for the system having software controlled FDB learning processing enabled and many line cards equipped, the capability of a CPU is a chiefly bottle-neck for performance involving many communication scenarios. Second, the synchronization is executed based on a timer timeout and some MAC address entry information is synchronized using chunk handling. This is also a common mechanism especially for the system having software controlled FDB learning processing enabled and many line cards equipped.
The mechanisms as discussed above are not ideal in view of the system resource consumption and performance. With respect to the immediate synchronization, it is very likely to engender CPU overload due to the fact that every MAC address triggers a synchronization action among all the line cards. With respect to the current timer based synchronization, it generally applies a common timer value to synchronize multiple MAC addresses among line cards and thus offers a non-differentiated synchronization mechanism. However, for a time-sensitive service, if the synchronization cannot be completed in a timely manner, it may cause traffic loss and even service disruption. Further, the adjustment of the timer leads to a difficult balance between bandwidth/CPU usage and performance/timeliness requirements for important applications. For instance, If the timer is set too short, it will confront with nearly the same issues as the immediate synchronization. On the other hand, if the timer is set too long, some key services sensitive to the timing would be impacted. Currently, due to constraints of the CPU and bandwidth, it is hard to satisfy some real-time requirements. For example, the VRRP is used to provide gateway resilience for the network and when the VRRP switches over, the port associated with the VRRP MAC address is changed. However, If the change is not reflected or synchronized timely, the traffic would be lost and service would even be disrupted. It can be understood that synchronization of MAC address changes among line cards is crucial in time-sensitive communication and should be solved appropriately.